构建数据湖上低延迟数据 Pipeline 的实践

T 推荐语 ·

数据加工的 Pipeline 是数据仓库建设的重要环节；数据入库的效率往往决定了分析数据的实时性，如何在数据湖上构建一个低延迟的数据 Pipeline，我们来看看 T3 出行是如何实践的。

云原生与数据湖是当今大数据领域最热的 2 个话题，本文着重从为什么传统数仓无法满足业务需求? 为何需要建设数据湖？数据湖整体技术架构、Apache Hudi 存储模式与视图、如何解决冷数据频繁更新、如何在数据湖上进行准实时分析、数据湖上调度为何选型 Apache DolphinScheduler、二次开发新特性以及规划等多个角度进行了阐述。

讲师介绍

杨华，T3 出行大数据平台负责人。Apache Hudi Committer & PMC、Apache Kylin Committer 及 Flink Cube 引擎作者。Apache Flink 国内早期布道者及活跃贡献者。曾在腾讯主导 Flink 在腾讯从落地到支撑日均近 20 万亿消息的处理。

赵玉威，T3 出行高级工程师，对大数据任务调度有深入研究。

这里也简要介绍一下 T3 出行：T3出行是由一汽、东风、长安联合腾讯、阿里巴巴等共同投资打造，有中国网约车“国家队”之称。

10 月 25 日的 COSCon’20 & Apache Roadshow - China 上，来自 T3 出行大数据平台负责人杨华和高级工程师赵玉威同学带来了题为《T3 出行构建数据湖上低延迟数据管道的实践》的分享。以下是分享视频: 

1

什么是数据湖

什么是数据湖

引用来自 AWS 对数据湖的定义：

A data lake is a centralized repository that allows you to store all yourstructured and unstructured data at any scale. You can store your data as-is,without having to first structure the data, and run different types ofanalytics—from dashboards and visualizations to big data processing, real-timeanalytics, and machine learning to guide better decisions.

数据湖是一个集中式的存储库，允许您以任意规模存储所有结构化和非结构化数据。您可以按原样存储数据（无需先对数据进行结构化处理），并运行不同类型的分析–从控制面板和可视化到大数据处理、实时分析和机器学习，以指导做出更好的决策。

2

 T3出行为什么需要数据湖

出行行业存在着下次出行前支付这个支付长尾问题，这造成了超长的业务闭环窗口，历史冷数据随机更新还有多级更新、链路长等特点，

T3 出行数据湖整体技术架构

数据湖框架 - Apache Hudi 简介

Hudi 插件化的架构

Hudi 存储模式与视图

T3 出行如何在数据湖上进行准实时分析

Hudi 与 DolphinScheduler 的集成

Why DolphinScheduler？

目前在业界应用较多的工作流调度系统包括 Oozie、Azkaban、Airflow 以及 Dolphin Scheduler 等。

从高可用、易用性、社区活跃度、可拓展性、与 Hadoop 生态圈集成以及维护成本几个维度进行了调研对比：

T3 出行 从EasyScheduler 升级为 DolphinScheduler

DolphinScheduler 最近发布的 1.3.2 版本，性能较 EasyScheduler 有 2~3 倍的提升，主要体现在调度策略、执行效率、单位时间吞吐、堆积处理等几个核心性能指标上。

DolphinScheduler 与 EasyScheduler 压测对比

l调度密度：调度周期为 1h，工作流每隔 20 秒调度一次l集群非调度时间内处于空闲状态，状态基本一致；在调度周期内只有工作流内的任务在耗用资源

DolphinScheduler 与 EasyScheduler系统运作的差异

在 DolphinScheduler 新架构(黑线)中 Master 职能更加丰富，Worker 则更加专注于执行。

在 EasyScheduler 中 Worker 不仅要主动“揽活”，还要负责“善后”工作。

任务的执行状态要通过访问数据库才能获得，对于那些任务复杂的工作流来说，时效性，任务吞吐，数据库压力都会成为调度性能的瓶颈。

DolphinScheduler 提升细节 - Netty 的引入

        在 EasyScheduler 架构中，由于 Master 与 Worker 间没有直接交互的渠道，因而使得 Master 的职能比较单一，同时降低了 Worker 的执行效率；两者通过第三方系统“曲线”通信带来的弊端是：耗费了大量时间与资源在数据库与ZooKeeper的操作上，牺牲性能以保障系统能够运作，这种过度使用底层组件的方式也为集群及调度自身的稳定埋下了隐患。

DolphinScheduler 提升细节 - Balance 机制

在 EasyScheduler 中 Worker的使用率与负载率难以均衡：

lMaster 只负责工作流的拆分，无法管控任务如何分发；

lWorker 通过非公平锁的方式从 zk 的任务队列中竞争拉取任务，无法合理分配

为此 DolphinScheduler 提供了三种任务分配策略：随机，轮询和资源线性加权。

Ø随机分发策略与非公平锁竞争类似；

Ø轮询分发策略只能保证使用率与负载率的均衡；

Ø资源线性加权根据 cpu，内存及 loadAverage 加权计算出各 worker 负荷指标，择优分发

线性加权是 DolphinScheduler 默认的分发策略，计算密集型或者内存紧吃的任务不会轻易得再由负荷较高的 Worker 去执行。

DolphinScheduler 提升细节 - 易用性提升

除了性能方面，社区也一直致力于易用性的提升，使调度对运维人员及业务开发人员更加亲和友好。

Ø支持 K8s：DolphinScheduler 支持 K8s 部署；

Ø简化配置：分离 install.sh 中的参数配置和集群部署配置，install.sh 仅供集群部署，集群参数配置文件抽取到 conf/config/install_config.conf 中；

Ø工作流布局优化：提供一键美化工作流 DAG 功能，这对于通过 http client 与调度交互时非常实用。开发人员只需要关注 DAG 中的依赖关系即可，坐标信息，连接信息交给格式化工具来处理。

3

  T3出行做了哪些改进

       在充分利用 DolphinScheduler 原生功能特性的基础上，基于平台与业务的赋能驱动，T3对 DolphinScheduler 进行了大量嵌入式开发，目的是：

l解决调度嵌入平台时遇到的兼容性问题，同时提供插件化所需的接口规范

l提供定制化任务类型的支持与现有任务类型的拓展

l特定场景下原生调度模式的适配及重构

l数仓业务由 EasyScheduler 向 DolphinScheduler 升级的版本兼容性问题

T3 开发调度新特性 - 调度场景拓展

提供 httpclient 用于平台内组件与 DolphinScheduler 交互。多数情况下，平台内业务都倾向于通过消息触发的方式与调度进行交互，通过 http client 调度可以将核心功能完全释放到平台侧，对于上层业务来说甚至不感知调度的存在。

通过平台可以对调度上的任务进行 CURD 操作，以及状态信息及日志的查看

T3 开发调度新特性 - 服务滚动升级

调度系统自适应平台最终体现在服务的变更，服务集成滚动升级是自适应的前提与低成本的保障。

T3 开发调度新特性 - 策略式通知管理

订阅式策略通知管理，细粒度的任务监控体系：ü策略动态配置、启用与屏蔽ü细粒度事件管理，避免通知时出现“羊群效应”ü同一事件源一对多告警群组ü同一群组内同一事件源单一触发

T3 开发调度新特性 - 对接 Prometheus

ü服务集成 PushGateway 完成指标推送ü多维度展示统计类与趋势变化类指标ü易拓展，支持指标定制化，动态生效

T3 正在doing - 事件驱动调度模式

事件驱动调度：把不同系统的业务逻辑用事件关联起来，来驱动业务或者流程继续执行。

l内部事件源：例如调度中一个工作流中的子任务节点，它是通过所有父节点执行完毕这个事件驱动触发的；

l外部事件源：例如外部某个组件，当其激活后需要立即拉起任务，获取数据以提供服务，”激活”就是事件

l事件重放：对于外部事件源，事件驱动只需要业务方抛出事件即可（异步任务调度除外），调度则应该负责持久化该事件以具备重放能力。

l解决方案：配置定时任务轮询捕获外部事件源虽然可行，但调度使用监听来驱动事件无疑更节约资源，任务触发实时性更高；并且事件中可以传递任务所须的参数，当调度监听到事件后解析参数然后组装成对应的任务，调度执行。

T3 正在doing - 异步回调调度模式

异步任务调度：核心是提供结果回调功能。

l使用场景：调度上某个任务执行完成后，需要将这个消息传达到外部以推动第三方系统内业务的流转，必要时消息中需要携带第三方所需的配置参数，结果信息等

l与事件驱动调度的区别：

    • 该场景下，调度系统任务结束成为了外部事件源

    • 调度系统不能只是简单地将事件抛出，还需兼顾延迟回调，回调失败重试，回调审计等功能

l解决方案：对于回调的方式，可以参考 hudi 使用的 http 回调，或者 Kafka回调。

T3 正在doing - 策略式任务集成

      当调度原生的任务类型无法满足业务线的个性需求时，需要不断地去适配，并且适配内容间鲜有共性，无法复用。对此，调度可以将差集内的任务执行策略交由业务自定义，自身负责策略模板的提供与执行策略的解析与管理。

T3 正在doing - 策略延迟调度

延迟任务调度：当任务提交后，在指定时间后延迟执行

l类似场景：包括用户下单后，一定时间后未付款自动关闭订单；用户打车后，一定时间后自动评价等

l常规方案与缺陷：扫描业务表，筛选出符合条件的数据对其进行操作，但存在扫描间隔影响任务延迟触发的精准性及可靠性等问题

l改进措施：调度维护延迟队列或在任务配置参数中新增延迟选项，即可以保证延迟执行的精确性，同时也能发挥自身高可用，可重试，能告警，提供管理视图的优势

4

  T3的未来规划

T3 打算做TODO - 运维管理

提供指标概览页面单独的统计类运维概览页面，通过图表的形式展示任务相关的统计类指标据，例如：

l近 M 天内执行时长的 TopN 实例或异常次数最多的 TopN 实例的柱状图；

l可以标识数据量变化或调度负载变化的实例近 M 天运行时长的折线图；

l提供 SQL 类图表生成器，可定制化

T3 打算做TODO - 路由策略

Ø故障转移：失败策略可选配置“故障转移”，工作节点故障后，自动 failover 切换到一台运行正常的工作点上重试

Ø忙碌转移：增加等待策略，当任务处于 WAITING 状态达到一定时间，由管理节点重新分配，尝试将任务转移到相对空闲的工作节点

T3 打算做TODO - 审计日志

T3 打算做TODO - 数据血缘

Ø血缘关系管理：记录上下游数据资源编码，数据项编码和数据资源转换规则等数据血缘信息，动态更新Ø血缘关系分析：对数据资源进行数据流向分析和溯源分析，更进一步可以提供数据血缘图谱展示Ø血缘关系查询：支持按照数据类别、数据项和转换规则进行数据血缘查询Ø数据价值评估：通过数据血缘标出数据流转的引用/更新频次，展示各级数据的应用热度

T3 打算做TODO - 调度客户端

l状态管理：提供命令行，方便监管调度服务状态，提供统计信息

       例如:   scheduler restart worker-server;    scheduler state 等

l任务管理器：不同于 http client 的 java 客户端形式，通过客户端脚本作为环境变量，以 shell 命令的方式拓展平台与调度的交互方式

       例如:   scheduler submit ...;    schedulerkill ...;     scheduler rerun ... 等

T3 打算做TODO - 跨集群调度与容灾

l跨集群调度：调度内服务通过标签的形式标识为不同集群组，提供类似 agent的服务由一个 ui 页面统一管理。

l容灾：在实现跨集群调度的基础上，主备集群容灾的全量与增量数据备份都可以通过调度定时完成，并通过调度提供的异步调度与事件通知机制来监管备份过程。

5

参与贡献

参与 DolphinScheduler 社区有非常多的参与贡献的方式，包括文档、翻译、布道、答疑、测试、以及代码等，此外也极其欢迎各种实践文章，DolphinScheduler开源社区非常期待您的参与。

贡献第一个PR(文档、代码) 我们也希望是简单的，试想如果是一个新人一上来就贡献1个改了几十个文件的 PR 将会对参与 review 的伙伴的心理造成多大的摧残，😝

如何参与贡献链接：https://dolphinscheduler.apache.org/zh-cn/docs/development/contribute.html

文档github地址：https://github.com/apache/incubator-dolphinscheduler-website

来吧，DolphinScheduler开源社区需要您的参与，为中国开源崛起添砖加瓦吧，哪怕只是小小的一块瓦，汇聚起来的力量也是巨大的

往期案例与实践

Kylin's Github Repo 传送门
↓↓↓https://github.com/apache/kylin喜欢❤️ Kylin 的话，别忘了 Star 🌟 一下哟～

点击“阅读原文”获取PPT资料